翻訳と辞書
Words near each other
・ Integrated receiver/decoder
・ Integrated reception system
・ Integrated Recreational Camps
・ Integrated Regional Water Management Planning
・ Integrated reporting
・ Integrated resort
・ Integrated Resort Scheme
・ Integrated Risk Management Services
・ Integrated Rural Development Program
・ Integrated Rural Technology Centre
・ Integrated Rutgers Information System
・ Integrated School of Ocean Sciences
・ Integrated Security Unit
・ Integrated Sensor is Structure
・ Integrated Service Provider
Integrated services
・ Integrated Services Digital Network
・ Integrated social work
・ Integrated software
・ Integrated Software Dependent System
・ Integrated Software for Imagers and Spectrometers
・ Integrated Soldier System Project
・ Integrated Space Cell
・ Integrated standby instrument system
・ Integrated Strategies
・ Integrated stress response
・ Integrated Support Command Alameda
・ Integrated Taxonomic Information System
・ Integrated Technology Group (ITG)
・ Integrated technology processes


Dictionary Lists
翻訳と辞書 辞書検索 [ 開発暫定版 ]
スポンサード リンク

Integrated services : ウィキペディア英語版
Integrated services
In computer networking, IntServ or integrated services is an architecture that specifies the elements to guarantee quality of service (QoS) on networks. IntServ can for example be used to allow video and sound to reach the receiver without interruption.
IntServ specifies a fine-grained QoS system, which is often contrasted with DiffServ's coarse-grained control system.
The idea of IntServ is that every router in the system implements IntServ, and every application that requires some kind of guarantees has to make an individual reservation. Flow Specs describe what the reservation is for, while RSVP is the underlying mechanism to signal it across the network.
==Flow Specs ==

There are two parts to a flow spec:
* What does the traffic look like? Done in the Traffic SPECification part, also known as TSPEC.
* What guarantees does it need? Done in the service Request SPECification part, also known as RSPEC.
TSPECs include token bucket algorithm parameters. The idea is that there is a token bucket which slowly fills up with tokens, arriving at a constant rate. Every packet which is sent requires a token, and if there are no tokens, then it cannot be sent. Thus, the rate at which tokens arrive dictates the average rate of traffic flow, while the depth of the bucket dictates how 'bursty' the traffic is allowed to be.
TSPECs typically just specify the token rate and the bucket depth. For example, a video with a refresh rate of 75 frames per second, with each frame taking 10 packets, might specify a token rate of 750 Hz, and a bucket depth of only 10. The bucket depth would be sufficient to accommodate the 'burst' associated with sending an entire frame all at once. On the other hand, a conversation would need a lower token rate, but a much higher bucket depth. This is because there are often pauses in conversations, so they can make do with less tokens by not sending the gaps between words and sentences. However, this means the bucket depth needs to be increased to compensate for the traffic being burstier.
RSPECs specify what requirements there are for the flow: it can be normal internet 'best effort', in which case no reservation is needed. This setting is likely to be used for webpages, FTP, and similar applications. The 'Controlled Load' setting mirrors the performance of a lightly loaded network: there may be occasional glitches when two people access the same resource by chance, but generally both delay and drop rate are fairly constant at the desired rate. This setting is likely to be used by soft QoS applications. The 'Guaranteed' setting gives an absolutely bounded service, where the delay is promised to never go above a desired amount, and packets never dropped, provided the traffic stays within spec.

抄文引用元・出典: フリー百科事典『 ウィキペディア(Wikipedia)
ウィキペディアで「Integrated services」の詳細全文を読む



スポンサード リンク
翻訳と辞書 : 翻訳のためのインターネットリソース

Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.